When a user commented on a page inside an entity they owned, they received a
notification for their own comment whenever the owner was a group they belong
to. The owner-side event addressed the owning entity (a group), and Backstage's
recipient resolver expanded that group back to its members — including the
actor.

The publisher had only ever excluded the actor by literal ref
(`recipients.filter(ref => ref \!== actorRef)`), which a group owner ref can
never match. Forward the actor as `excludeEntityRef` on the notification
recipients instead: Backstage's resolver drops the actor from the resolved set
after expanding groups, covering group, nested-group, and direct-user owners
alike. This is the field's documented purpose ("the currently logged-in user,
for preventing sending notification of user action to him/herself").

With exclusion now correct at delivery, the publisher's literal-ref pre-filter
(and its empty-recipients early-exit) was redundant — `excludeEntityRef` is a
strict superset. Remove it so actor exclusion has a single home: the publisher
emits the raw section owner / thread participants (which may include the actor)
and the resolver drops the actor. Trade-off: self-comments and sole-participant
threads now publish an event that resolves to zero recipients instead of being
skipped locally; the wasted work is one publish + one notification POST (no
catalog expansion for the direct-user case).

Validates `actorRef` in the subscriber's shape guard (the sole basis for
exclusion now) and adds regression coverage, including an owner==actor publisher
test that fails if the literal filter is reintroduced.

Verified e2e: a group member commenting on their own entity gets nothing; a
non-member still notifies the member owners; an owner commenting on a directly
owned entity gets nothing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>